This code is shared across all supported integrations, we shouldn't be really making hacks for particular databases here since we already use inheritance to customize the behavior of schema generation. Imagine if we start handling all edge cases for all databases here - the code will become unreadable pretty soon.

Looks like the issue is coming from https://github.com/tortoise/tortoise-orm/blob/develop/tortoise/indexes.py#L62. What is going to happen if we replace self.INDEX_CREATE_TEMPLATE with schema_generator.INDEX_CREATE_TEMPLATE?

I think it would be more correct to get rid of Index.get_sql altogether and just implement SQL generation for Index in schema_generator subclass, hence being able to customize it for each database.

@henadzit I add a class _db_mysql to the Index class.

@waketzheng what do you think about my other suggestions? We work quite a lot together on this project and it would help a lot if we communicate better. In this example it would help if you shared your thoughts on why you decided to approach this problem in a different way than you initially planned or than proposed by me.

I think it would be more correct to get rid of Index.get_sql altogether and just implement SQL generation for Index in schema_generator subclass, hence being able to customize it for each database.

What is going to happen if we replace self.INDEX_CREATE_TEMPLATE with schema_generator.INDEX_CREATE_TEMPLATE?

@henadzit I think word is limit. For me, code is much easy to understand than word. Many many times, I was able to get the point why sb code like that quickly without reading any comments.
This PR was expected to be a hotfix for the BUG. It may not be the best solution for the creation of Index. But keep the library work correctly is more important that make code better. I would rather fix bug soon and leave the refactor job later.
Why not replace self.INDEX_CREATE_TEMPLATE with schema_generator.INDEX_CREATE_TEMPLATE:

As the above picture showing, both tortoise/backends/mysql/schema_generator.py and tortoise.indexes.py have a INDEX_CREATE_TEMPLATE var, and they are different value. It mean that get rid of Index.get_sql altogether in schema_generator will cost much time to do the refactor. Let's keep small step forward, don't change too much in such a hotfix PR!

1. It isn't a hot fix PR since the bug hasn't gotten into any release.
2. I proposed the changes and you ignored my comments pretty much and made other changes. That isn't just about getting the point, it's simple politeness.
3. if you look at any successful open-source projects, you will see a lot of discussions and good communication.
4. Your changes at the moment aren't just a bug fix. You are introducing a new concept where the create index statements can be customized via class _db_*. The way it works in open-source and pretty much in any software development, other people will start following the pattern and extending the code base in a similar manner.
5. We need to be trying to improve the code base with each our change, otherwise it will decay pretty quickly. "I will do a hot fix and then we refactor it later" rarely works.

I'll give a shot at this issue to see if there is an approach where we can simplify things.

@henadzit

1. No matter whether it is a hot fix or not, we should keep the develop branch work fine.
2. Actually, I try your suggestion get rid of Index.get in schema_generator and find it hard to do that, so I push commits with another solution, I expected to get your response after compare these two solutions.
3. I read some PRs in poetry and fastapi, they did communicate a lot, but sometimes replied after several weeks. It is my pleasure that if we can communicate quickly and smoothly.
4. class _db_* is not a new concept, you can find it at https://github.com/tortoise/tortoise-orm/blob/develop/tortoise/fields/data.py#L90
5. Everyone have only 24 hours one day, we should focus on crucial things, "rarely" mean that there are jobs more important that this one.

I'll give a shot at this issue to see if there is an approach where we can simplify things.
OK, I'll pull your branch to local and add some tests.

This hides the issue that Index cannot be described in a serializable way, however, it doesn't fix it. I fixed it in my PR by implementing Index.describe.

It looks like you added this index because it exposes the issue with serializing Index in Model.describe. I was able to identify it only because I worked on the same issue in my PR, it wouldn't be clear to anyone reviewing this PR.

Even though this index exposes an issue, it isn't documented and completely not obvious why it is here. Someone can remove it later without knowing its purpose and the same regression can happen again. I added a dedicated class for testing indexes in my PR.